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Introduction 

The  Internet  Protocol  (IP)  [1]  Is  used  for  host~to-host  datagram 
service  In  a  system  of  Interconnected  networks  called  the 
Catenet  [2].  The  network  connecting  devices  are  called  Gateways. 
These  gateways  communicate  between  themselves  for  control  purposes 
via  a  Gateway  to  Gateway  Protocol  (GGP)  [3,4].  Occasionally  a 
gateway  or  destination  host  will  communicate  with  a  source  host,  for 
example,  to  report  an  error  In  datagram  processing.  For  such 
purposes  this  protocol,  the  Internet  Control  Message  Protocol  (ICMP), 
Is  used.  ICMP,  uses  the  basic  support  of  IP  as  If  It  were  a  higher 
level  protocol,  however,  ICMP  Is  actually  an  Integral  part  of  IP,  and 
must  be  Implemented  by  every  IP  module. 

ICMP  messages  are  sent  In  several  situations:  for  example,  when  a 
datagram  cannot  reach  Its  destination,  when  the  gateway  does  not  have 
the  buffering  capacity  to  forward  a  datagram,  and  when  the  gateway 
can  direct  the  host  to  send  traffic  on  a  shorter  route. 

The  Internet  Protocol  Is  not  designed  to  be  absolutely  reliable.  The 
purpose  'of  these  contra!  messages  Is  to  provide  feedback  about 
problems  In  the  communication  environment,  not  to  make  IP  reliable. 
There  are  still  no  guarantees  that  a  datagram  will  be  delivered  or  a 
control  message  will  be  returned.  Some  datagrams  may  still  be 
undelivered  without  any  report  of  their  loss.  The  higher  level 
protocols  that  use  IP  must  Implement  their  own  reliability  procedures 
if  reliable  communication  Is  required. 

The  ICMP  messages  typically  report  errors  In  the  processing  of 
datagrams.  To  avoid  the  infinite  regress  of  messages  about  messages 
etc.,  no  ICMP  messages  are  sent  about  ICMP  messages.  Also  ICMP 
messages  are  only  sent  about  errors  In  handling  fragment  zero  of 
fragemented  datagrams.  (Fragment  zero  has  the  fragment  offeset  equal 
zero) . 
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Message  Formats 

ICMP  massagas  ara  sant  using  tha  basic  IP  haadar.  Tba  first  octat  of 
the  data  portion  of  tha  datagram  Is  a  ICMP  typa  flald;  tha  valua  of 
this  flald  datarmlnas  tha  format  of  tha  ramalnlng  data.  Any  flald 
labalad  "unused”  Is  rasarvad  for  latar  axtanslons  and  must  ba  zero 
when  sant,  but  racalvars  should  not  usa  thasa  fields  (except  to 
Include  them  In  tha  checksum).  Unless  otherwise  noted  uAder  tha 
Individual  format  descriptions,  tha  values  of  the  Internet  header 
fields  are  as  follows: 

Version 

4 


IHL 


Internet  haadar  length  In  32-bit  words. 

Type  of  Service 
0 

Total  Length 

Length  of  Internet  haadar  and  data  In  octets. 

Identification,  Flags.  Fragment  Offset 
Used  In  fragmentation,  sea  [1]. 

Time  to  Live 

Tima  to  live  In  seconds;  as  this  field  Is  decremented  at  each 
machine  In  which  tha  datagram  Is  processed,  tha  value  In  this 
field  should  ba  at  least  as  great  as  the  number  of  gateways  which 
this  datagram  will  traverse. 

Protocol 

ICMP  ■  1 

'Header  Checksum 

The  16  bit  one’s  complement  of  the  one’s  complement  sum  of  all  16 
bit  words  in  the. header.  For  computing  the  checksum,  the  checksum 
field  should  be  zero.  This  checksum  may  be  replaced  In  the 
future. 
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Source  Addr«ss 

The  address  of  ths  gateway  or  host  that  composes  the  ICMP  message. 
Unless  otherwise  noted,  this  can  be  any  of  a  gateway's  addresses. 

Destination  Address 

The  address  of  the  gateway  or  host  to  which  the  message  should  be 
sent. 


Ascension  For 
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Destination  Unreachable  Message 

0  12  3 

01234567890123466789012348878901 

|  Type  |  Code  |  Checksum  | 

+~4— 4-+-+-<4-+-+~f-4—+-+-+-+-+— 4-4-4— 4~+-+-+— ♦.-+—4—4 

|  unused  | 

4*+»4*+*+“+-+«+*+*+-4*+*+*+*+«+«+«+*+*+«+-+-+»4«4«+«+»<f»4«+«4«4«+ 

|  Internet  Header  ♦  64  bits  of  Original  Data  Datagram  | 

+-+—4—4-4— 4-4— 4-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— +-+-+-+-+-+-+ 

IP  Fields: 

Destination  Address 

The  source  network  and  address  from  the  original  datagram's  data. 
ICMP  Fields: 

Type 

3 

Code 

0  >  net  unreachable: 

1  »  host  unreachable: 

2  •  protocol  unreachable; 

3  •  port  unreachable; 

4  ■  fragmentation  needed  and  DF  set; 

6  ■  source  route  failed. 

Checksum 

The  checksum  Is  the'  16-bit  ones’s  complement  of  the  one’s 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  .  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  In  the  future. 

Internet  Header  +  64  bits  of  Data  Datagram 

The  Internet  header  plus  the  first  64  bits  of  the  original 
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datagram's  data.  This  data  is  ustd  by  tha  host  to  natch  the 
Message  to  the  appropriate  process.  If  a  higher  lovel  protocol 
uses  port  numbers,  they  are  assumed  to  be  In  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

If,  according  to  the  Information  in  the  gateway's  routing  tables, 
the  network  specified  in  the  Internet  destination  field  of  a 
datagram  Is  unreachable,  e.g..  the  distance  to  tbm  network  Is 
infinity,  the  gateway  may  send  a  destination  unremchable  message 
to  the  Internet  source  host  of  the  datagram.  In  addition,  in  some 
networks,  the  gateway  may  be  able  to  determine  If  the  internet 
destination  host  Is  unreachable.  Gateways  in  thesm  networks  may 
send  destination  unreachable  messages  to  the  sourcm  host  when  the 
destination  host  Is  unreachable. 

if,  in  the  destination  host,  the  IP  module  cannot  deliver  the 
datagram  because  the  indicated  protocol  module  or  process  port  Is 
not  active,  the  destination  host  may  send  a  destination 
unreachable  message  to  the  source  host. 

Another  case  is  when  a  datagram  must  be  fragmented  to  be  forwarded 
by  a  gateway  yet  the  Oon't  Fragment  flag  Is  on.  Im  this  case  the 
gateway  must  discard  the  datagram  and  may  return  *  destination 
unreachable  message. 

Codes  0,  1,  4,  and  5  may  be  received  from  a  gateway.  Codes  Z  and 
3  may  be  received  from  a  host. 
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TIm  Exceeded  M«tug« 


0  12  3 

01234667890123466789012345678901 

♦*+-+»+*+*+»+”*«+»+*+i,+*+*+“+*+”+***+*+«+"+*+*^”+"+*+^«+*+*+”+*+ 


|  Type  |  Cod*  |  Checksum  | 


|  unused  *  | 

|  Internet  Header  *  64  bits  of  Original  Data  Datagram  | 


♦-+-+-+-4— f-4 


IP  Fields: 

Destination  Address 

The  source  network  and  address  froa  the  original  tfmtagram's  data. 
ICMP  Fields: 

Type 

11 

Code 

0  ■  time  to  live  exceeded  In  transit; 

1  ■  fragment  reassembly  time  exceeded. 

Checksum 

The  checksum  Is  the  16-bit  ones’ s  complement  of  tfcm  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  .  the  checksum  field  sliould  be  zero. 
This  checksum  may  be  replaced  In  the  future. 

Internet  Header  +  64  bits  of  Data  Datagram 

The  Internet  header  plus  the  first  64  bits  of  thm  original 
datagram's  data.  This  data  Is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  arc  assumed  to  be  In  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

If  the  gateway  processing  a  datagram  finds  the  time  to  live  field 
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Is  zero  It  must  discard  the  datagram.  The  gateway  may  also  notify 
the  source  host  via  the  time  exceeded  message. 

If  a  host  reassembling  a  fragmented  datagram  cannot  complete  the 
reassembly  due  to  missing  fragments  within  Its  time  limit  it 
discards  the  datagram,  and  it  may  send  a  time  exceeded  message. 

If  fragment  zero  is  not  available  then  no  time  exceeded  need  be 
sent  at  all. 

Code  0  may  be  received  from  a  gateway.  Code  1  may  be  received 
from  a  host. 
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Parameter  Problem  Message 

0  12  3 

01234567890123456789012345678901 

f— +-4—+-+-+-+-+-4—4— 

|  Type  |  Code  |  Checksum  | 

|  Pointer  |  unused  | 

+-+-+-+-+-4>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— ♦— +~ f 

|  Internet  Header  ♦  64  bits  of  Original  Data  Datagram  | 

►-♦-+-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— *-+-+-+ 


IP  Fields: 

Destination  Address 

The  source  network  and  address  from  the  original  datagram's  data. 
ICMP  Fields: 

Type 

12 

Code 

0  ■  pointer  Indicates  the  error. 

Checksum 

The  checksum  Is  the  18-bit  ones’s  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  .  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  In  the  future. 

Pointer 

If  code  *  0,  Identifies  the  octet  where  an  error  was  detected. 

Internet  Header  +  64  bits  of  Data  Datagram 

The  Internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  Is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  In  the  first  64  data 
bits  of  the  original  datagram's  data. 
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Description 

If  the  gateway  or  host  processing  a  datagram  finds  a  problem  with 
the  header  parameters  such  that  It  cannot  complete  processing  the 
datagram  It  must  discard  the  datagram.  One  potential  source  of 
such  a  problem  Is  with  Incorrect  arguments  in  an  option.  The 
gateway  or  host  may  also  notify  the  source  host  via  the  parameter 
problem  message.  This  message  is  only  sent  If  the  error  caused 
the  datagram  to  be  discarded. 

The  pointer  identifies  the  octet  of  the  original  datagram's  header 
where  the  error  was  detected  (it  may  be  in  the  middle  of  an 
option).  For  example,  1  Indicates  something  is  wrong  with  the 
Type  of  Service,  and  (if  there  are  options  present)  20  indicates 
something  Is  wrong  with  the  type  code  of  the  first  option. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Source  Quench  Message 

0  12  3 

01234567890123456789012345678901 

I  Type  |  Code  i  Checksum  | 

+-+-♦-♦-+“+-+-+-+-+-+-+-+-+-+-+-+'•+-+-+-+-+-4— 

|  unused  *  | 

|  Internet  Header  +  84  bits  of  Original  Data  Datagram  | 


IP  Fields: 

Destination  Address 

The  source  network  and  address  of  the  original  datagram*  data. 
ICMP  Fields: 

Type 

4 

Code 

0 

Checksum 

The  checksum  is  the  16-bit  ones's  complement  of  tha  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  In  the  future. 

Internet  Header  +  64  bits  of  Data  Datagram 

The  Internet  header  plus  the  first  64  bits  of  the  original 
datagram's  data.  This  data  Is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

Description 

A  gateway  may  discard  internet  datagrams  if  It  does  not  have  the 
buffer  space  needed  to  queue  the  datagrams  for  output  to  the  next 
network  on  the  route  to  the  destination  network.  If  a  gateway 
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discards  a  datagram.  It  may  send  a  source  quench  message  to  the 
Internet  source  host  of  the  datagram.  A  destination  host  may  also 
send  a  source  quench  message  If  datagrams  arrive  too  fast  to  be 
processed.  The  source  quench  message  Is  a  request  to  the  host  to 
cut  back  the  rate  at  which  It  Is  sending  traffic  to  the  Internet 
destination.  The  gateway  may  send  a  source  quench  message  for 
every  message  that  It  discards.  On  receipt  of  a  source  quench 
message,  the  source  host  should  cut  back  the  rate  at  which  It  Is 
sending  traffic  to  the  specified  destination  until  It  no  longer 
receives  source  quench  messages  from  the  gateway.  The  source  host 
can  then  gradually  Increase  the  rate  at  which  It  sends  traffic  to 
the  destination  until  It  again  receives  source  quench  messages. 

The  gateway  or  host  may  send  the  source  quench  message  when  It 
approaches  Its  capacity  limit  rather  than  waiting  until  the 
capacity  Is  exceeded.  This  means  that  the  data  datagram  which 
triggered  the  source  quench  message  may  be  delivered. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Redirect  Message 

0  12  3 

01234567890123458789012345878901 

|  Type  |  Code  |  Checksum  | 

|  Gateway  Internet  Address  | 

♦>-+-+-♦-+-+-+-+-4— 

|  Internet  Header  64  bits  of  Original  Oata  Datagram  | 

4-+-+-+-+-+-+-+-+-4— ►-4—4— +-+-+— ► 


IP  Fields: 
Destination  Address 


The  source  network  and  address  of  the  original  datagram's  data. 


ICMP  Fields: 
Type 
5 


Code 


0  »  Redirect  datagrams  for 

1  »  Redirect  datagrams  for 

2  *  Redirect  datagrams  for 

3  *  Redirect  datagrams  for 

Checksum 


the  Network, 
the  Host. 

the  Type  of  Service  and  Network, 
the  Type  of  Service  and  Host. 


The  checksum  is  the  16-bit  ones's  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 


Gateway  Internet  Address 


Address  of  the  gateway  to  which  traffic  for  the  network  specified 
In  the  Internet  destination  network  field  of  the  original 
datagram's  data  should  be  sent. 
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Internet  Header  +  64  bits  of  Uata  Datagram 

The  internet  header  plus  the  first  64  bits  of  the  original 
datagram’s  data.  This  data  is  used  by  the  host  to  match  the 
message  to  the  appropriate  process.  If  a  higher  level  protocol 
uses  port  numbers,  they  are  assumed  to  be  in  the  first  64  data 
bits  of  the  original  datagram's  data. 

r 

Description 

The  gateway  sends  a  redirect  message  to  a  host  in  the  following 
situation.  A  gateway,  Gl,  receives  an  internet  datagram  from  a 
host  on  a  network  to  which  the  gateway  is  attached.  The  gateway, 
Gl.  checks  its  routing  table  and  obtains  the  address  of  the  next 
gateway,  G2,  on  the  route  to  the  datagram's  internet  destination 
network.  X.  If  G2  and  the  host  identified  by  the  internet  source 
address  of  the  datagram  are  on  the  same  network,  a  redirect 
message  is  sent  to  the  host.  The  redirect  message  advises  the 
host  to  send  its  traffic  for  network  X  directly  to  gateway  G2  as 
this  is  a  shorter  path  to  the  destination.  The  gateway  forwards 
the  original  datagram's  data  to  its  Internet  destination. 

For  datagrams  with  the  IP  source  route  options  and  the  gateway 
address  in  the  destination  address  field,  a  redirect  message  is 
not  sent  even  if  there  is  a  better  route  to  the  ultimate 
destination  than  the  next  address  in  the  source  route. 

Codes  0,  1,  2,  and  3  may  be  received  from  a  gateway. 
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Echo  or  Echo  Reply  Message 

0  12  3 

01234567890123466789012345678901 

|  Type  |  Code  |  Checksum  | 

♦-+-+-4— 4-+-+-+-+— f~4-+-+-4-4-+-+-+-+-4-4-4-4-4-4~4-4-4— 4-+-4— ♦— 4 

|  Identifier  |  Sequence  Number*  | 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

|  Data  . . . 

+-+-4-4-4- 

IP  Fields: 

Addresses 

The  address  of  the  source  in  an  echo  message  will  be  the 
destination  of  the  echo  reply  message.  To  form  an  echo  reply 
message,  the  source  and  destination  addresses  are  simply  reversed, 
the  type  code  changed  to  0,  and  the  checksum  recomputed. 

IP  Fields: 

Type 

8  for  echo  message; 

0  for  echo  reply  message. 

Code 

0 

Checksum 

The  checksum  is  the  16-bit  ones’s  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 

For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 

If  the  total  length  Is  odd,  the  received  data  is  padded  with  one 
octet  of  zeros  for  computing  the  checksum.  This  checksum  may  be 
replaced  In  the  future. 

Identifier 

If  code  ■  0,  an  Identifier  to  aid  In  matching  echos  and  replies, 
may  be  zero. 

Sequence  Number 
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If  code  ■  0,  a  sequence  number  to  aid  In  matching  echos  and 
replies,  may  be  zero. 

Description 

* 

The  data  received  In  the  echo  message  must  be  returned  In  the  echo 
reply  message. 

The  Identifier  and  sequence  number  may  be  used  by  the  echo  sender 
to  aid  In  matching  the  replies  with  the  echo  requests.  For 
example,  the  Identifier  might  be  used  like  a  port  In  TCP  or  UDP  to 
Identify  a  session,  and  the  sequence  number  might  be  Incremented 
on  each  echo  request  sent.  The  echoer  returns  these  same  values 
In  the  echo  reply. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Timestamp  or  Timestamp  Reply  Message 

0  12  3 

01234567890123468789012348678901 

I  Type  |  Code  |  Checksum  | 

♦-+-+-+-♦-♦-♦-+-+-+-♦-♦-+-+-+-♦-+-+-♦-+-+-+-+-4-+-+-+— *-+-+-+-+-+ 

|  Identifier  |  Sequence  Number  | 

♦_4-4-4-4-4-4-4-4“4“4“4-4-4“4-4-4-+-+-4-4—4-4-+-4-4-4— 4-4-4»4-+-4 

|  Originate  Timestamp  | 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

|  Receive  Timestamp  | 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

|  Transmit  Timestamp  | 

4-4~4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 


IP  Fields: 

Addresses 

• 

The  address  of  the  source  in  a  timestamp  message  will  bo  the 
destination  of  the  timestamp  reply  message.  To  form  a  timestamp 
reply  message,  the  source  and  destination  addresses  are  simply 
reversed,  the  type  code  changed  to  14.  and  the  checksum 
recomputed. 

IP  Fields: 

Type 

13  for  timestamp  message; 

14  for  timestamp  reply  message. 

Code 

0 

Checksum 

The  checksum  Is  the  16-bit  ones' s  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 
For  computing  the  checksum  ,  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  In  the  future. 

Identifier 
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If  code  ■  0.  an  Identifier  to  aid  in  matching  timestamp  and 
replies,  may  be  zero. 

Sequence  Number 

If  code  »  0,  a  sequence  number  to  aid  in  matching  timestamp  and 
replies,  may  be  zero. 

Description 

The  data  received  (a  timestamp)  in  the  message  is  returned  in  the 
reply  together  with  an  additional  timestamp.  The  timestamp  is  32 
bits  of  milliseconds  since  midnight  UT.  One  use  of  these 
timestamps  is  described  by  Mills  [5]. 

The  Originate  Timestamp  is  the  time  the  sender  last  touched  the 
message  before  sending  it.  the  Receive  Timestamp  Is  the  time  the 
echoer  first  touched  it  on  receipt,  and  the  Transmit  Timestamp  is 
the  time  the  echoer  last  touched  the  message  on  sending  It. 

If  the  time  Is  not  available  in  miliseconds  or  cannot  be  provided 
with  respect  to  midnight  UT  then  any  time  can  be  Inserted  in  a 
timestamp  provided  the  high  order  bit  of  the  timestamp  is  also  set 
to  indicate  this  non-standard  value. 


The  identifier  and  sequence  number  may  be  used  by  the  echo  sender 
to  aid  in  matching  the  replies  with  the  requests.  For  example, 
the  identifier  might  be  used  like  a  port  in  TCP  or  UDP  to  identify 
a  session,  and  the  sequence  number  might  be  incremented  on  each 
request  sent.  The  destination  returns  these  same  values  in  the 
reply. 

Code  0  may  be  received  from  a  gateway  or  a  host. 
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Information  Request  or  Information  Reply  Message 

0  12  3 

01234567890123456789012345678901 

4-4-4-4-4-4-4-4-4-+-+-+— «~4-4-4-4-4-4-4— ♦— 4-4-4-4- 4-4-4-4-+-4-4-+ 

|  Type  |  Code  |  Checksum  | 

+-+-4— f-+-+-+«+~4-+-+~f-+-+“+“+-+-+-+-+~+— 

|  Identifier  |  Sequence  Number1  | 

+-+-4-+-+— ♦—+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-4-+-+-+-+-+-+-+-+-+-+ 

IP  Fields: 

Addresses 

The  address  of  the  source  in  a  information  request  message  will  be 
the  destination  of  the  information  reply  message.  To  form  a 
information  reply  message,  the  source  and  destination  addresses 
are  simply  reversed,  the  type  code  changed  to  16.  and  the  checksum 
recomputed. 

IP  F ields: 

Type 

15  far  information  request  message; 

16  for  information  reply  message. 

Code 

0 

Checksum 

The  checksum  is  the  16-bit  ones's  complement  of  the  one's 
complement  sum  of  the  ICMP  message  starting  with  the  ICMP  Type. 

For  computing  the  checksum  .  the  checksum  field  should  be  zero. 
This  checksum  may  be  replaced  in  the  future. 

Identifier 

If  code  •  0.  an  Identifier  to  aid  in  matching  request  and  replies, 
may  be  zero. 

Sequence  Number 

If  code  ■  0,  a  sequence  number  to  aid  in  matching  request  and 
replies,  may  be  zero. 
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Description 

This  message  may  ba  sant  with  the  source  network  In  the  IP  header 
source  and  destination  address  fields  zero  (which  means  "this" 
network).  The  replying  IP  module  should  send  tha  reply  with  the 
addresses  fully  specified.  This  message  Is  a  way  for  a  host  to 
find  out  the  number  of  the  network  It  Is  on. 

The  Identifier  and  sequence  number  may  be  used  by  the  echo  sender 
to  aid  In  matching  the  replies  with  the  requests.  For  example, 
the  Identifier  might  be  used  like  a  port  In  TCP  or  UOP  to  Identify 
a  session,  and  the  sequence  number  might  be  Incremented  on  each 
request  sent.  The  destination  returns  these  same  values  In  the 
reply. 

Code  0  may  be  received  from  a  gateway  or  a  host. 


nr 
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Summary  of  Massage  Types 
0  Echo  Reply 

.3  Destination  Unreachable 

4  Source  Quench 

5  Redirect 
8  Echo 

11  Time  Exceeded 

12  Parameter  Problem 

13  Timestamp 

14  Timestamp  Reply 

15  Information  Request 

16  Information  Reply 


[Page  20] 


September  1981 
RFC  792 


References 

[1]  Postel,  J.  (ed.).  "Internet  Protocol  -  DARPA  Internet  Program 

Protocol  Specification,"  RFC  791,  USC/Information  Sciences 
Institute,  September  1981. 

[2]  Cerf,  V.,  "The  Catenet  Model  for  Internetworking."  IEN  48, 
Information  Processing  Techniques  Office,  Defense  Advanced 
Research  Projects  Agency,  July  1978. 

[3]  Strazisar,  V.,  "Gateway  Routing:  An  Implementation 
Specification”,  IEN  30,  Bolt  Beranek  and  Newman,  April  1979. 

[4]  Strazisar,  V.,  "How  to  Build  a  Gateway",  IEN  109,  Bolt  Beranek 
and  Newman.  August  1979. 

[5]  Mills,  0..  "DCNET  Internet  Clock  Service,"  RFC  778,  COMSAT 
Laboratories.  April  1981. 


FILMED 

9 

2-83 

DTIC 


